Virtualized communication sockets for multi-flow access to message channel infrastructure within cpu

ABSTRACT

A message channel optimization method and system enables multi-flow access to the message channel infrastructure within a CPU of a processor-based system. A user (pcode) employs a virtual channel to submit message channel transactions, with the message channel driver processing the transaction “behind the scenes”. The message channel driver thus allows the user to continue processing without having to block other transactions from being processed. Each transaction will be processed, either immediately or at some future time, by the message channel driver. The message channel optimization method and system are useful for tasks involving message channel transactions as well as non-message channel transactions.

TECHNICAL FIELD

This application relates to multiprocessor systems, portable machinecode, and message channel transaction processing.

BACKGROUND

FIG. 1 is a simplified block diagram of a multiprocessor system 500,according to some embodiments. The multiprocessor system 500 includes Ncentral processing units (CPUs) 150A, 150B, 150N (collectively, “CPUs150”), which are coupled to N-1 specialized busses, known as quick pathinterconnect (QPI) busses 160A, 160B, . . . , 160N-1 (collectively, “QPIbusses 160”). The QPI busses 160, specifically designed for the CPUs,speed up communication between the CPUs 150. The CPUs may also becoupled to one or more volatile memories (not shown).

Also featured in the multiprocessor system 500 are up to N peripheralcontroller hubs (PCHs) 180A, . . . , 180N (collectively, “PCHs 180”)coupled to the CPUs 150 via up to N specialized busses, known as directmedia interface (DMI) busses 170A, 1708, . . . , 170N. The PCHs 180interface between the CPUs 150 and one or more peripheral devices of themultiprocessor system 500. The PCHs 180 may include display,input/output (I/O) control, a real-time clock, and other functions andmay connect to an integrated display as well as other peripheraldevices, such as a keyboard, a mouse, a non-volatile storage device, andso on.

For communication between endpoints within the processor of amultiprocessor system 500 or a single processor-based system, a messagechannel is used. The message channel is the transmission medium forthese communications, and may be thought of as a type of “tunnel” or“subway” between end points inside the processor. There may be manymessage channel endpoints, and a message may be sent from any endpointto any other endpoint, with the endpoints being functional entitieswithin the processor. Portable machine code, or pcode, is used tocommunicate between the entities, and the pcode has its own endpoint forsending messages to other endpoints. (No endpoint sends an autonomousmessage to the pcode, as the only message that is received by the pcodeendpoint is a response to a message that the pcode originated.) Powermanagement request (PMReq) messages go to other entities using the QPIbus, which is similar to the message channel, except that the QPI bus isan external bus/interface. The message channel, by contrast, is strictlyinternal to the processor.

In CPU-based systems, such as a single-processor system or themultiprocessor system 500 of FIG. 1, a message channel is used by manydisparate pcode flows and functions. These functions may be used to readand write encore control registers, issue PMReqs, and send messages toother platform entities (e.g., other CPUs 150, PCHs 180). The pcode usesthe message channel quite frequently, from hundreds of times permillisecond to thousands of times per millisecond.

Some newer multiprocessor systems are designed in such a way that themessage channel may become blocked at various times, such as during afrequency transition. Previous multiprocessor systems did not have thisissue, as their message channel interfaces were always fully functional.So, the pcode in previous projects could use the message channel in a“blocking” manner by sending the transaction onto the message channel,and waiting in a tight loop for the completion of the transaction.

For newer multiprocessor systems, the use of “blocking” transactions onthe message channel is deemed unacceptable because the blockingtransaction can potentially lock up pcode for several tens ofmicroseconds. The blocking transactions thus lead to a higher latencyfor other (non-message-channel-related) functions and impact theperformance of the CPU. In addition, there is a risk of a deadlockbecause the message channel is blocked by some function that is waitingfor something from the pcode via a sideband interface, but the pcode isblocked waiting for a message channel transaction to complete.

Additionally, PMreq messages require arbitration for use of a singlebuffer in a PMReq engine (PME).PMreq messages go over the messagechannel to the PME, and then over the QPI bus 160 to another CPU 150 (orover the DMI bus 170 to the PCH 180). As part of the PMreq protocolcorrectness, the PMEwill wait for a completion (CMP) from the otherCPU/PCH, and will keep the PMReq buffer locked until the completion isactually received. In this case, if a blocking message channeltransaction is used, the pcode will be locked up for the entireround-trip duration of the PMreq/CMP exchange. There may be delays onthe other CPU (due to a frequency change, etc.), which further prolongsthe duration of the lock-up.

Thus, there is a continuing need for a solution that overcomes theshortcomings of the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisdocument will become more readily appreciated as the same becomes betterunderstood by reference to the following detailed description, whentaken in conjunction with the accompanying drawings, wherein likereference numerals refer to like parts throughout the various views,unless otherwise specified.

FIG. 1 is a simplified block diagram of a multiprocessor system,according to some embodiments;

FIG. 2 is a simplified block diagram of the message channel optimizationmethod and system, according to some embodiments;

FIG. 3 is a flow diagram showing task flow for two tasks, according tosome embodiments;

FIG. 4 is a flow diagram showing task flow for the same two tasks as inFIG. 3, this time using the method and system of FIG. 2, according tosome embodiments;

FIG. 5 is a simplified block diagram showing the tools used by theoptimization method and system of FIG. 2, according to some embodiments;

FIG. 6 is a flow diagram following a message channel send operation asprocessed by the message channel optimization method and system of FIG.2, according to some embodiments; and

FIG. 7 is a flow diagram following a message channel read operation asprocessed by the message channel optimization method and system of FIG.2, according to some embodiments.

DETAILED DESCRIPTION

In accordance with the embodiments described herein, a virtual messagechannel and driver are disclosed for enabling multi-flow access to themessage channel infrastructure within a CPU of a processor-based system.Each pcode flow that uses the message channel is assigned a virtualchannel identifier. Each flow with a virtual channel identifier canregister a callback address and can submit one message channeltransaction for processing. The transaction will be processed, eitherimmediately or at some future time, by a message channel driver.

In the following detailed description, reference is made to theaccompanying drawings, which show by way of illustration specificembodiments in which the subject matter described herein may bepracticed. However, it is to be understood that other embodiments willbecome apparent to those of ordinary skill in the art upon reading thisdisclosure. The following detailed description is, therefore, not to beconstrued in a limiting sense, as the scope of the subject matter isdefined by the claims.

FIG. 2 is a simplified block diagram of a message channel optimizationmethod 100, or optimization method 100, according to some embodiments.The optimization method 100 employs virtualized communication socketsfor enabling multi-flow access to the message channel infrastructure ofa processor-based system. The optimization method 100 uses a messagechannel driver 50 to interface between virtual channels 70A, 706, . . ., 70K (collectively, “virtual channels 70”) and a physical messagechannel 20 that is used for communication between endpoints within aprocessor of the processor-based system.

In some embodiments, the optimization method 100 solves the issuesdescribed in the background section for systems such as themultiprocessor system 500 of FIG. 1, by using the virtual messagechannels 70 rather than blocking use of the message channel 50. Althoughthe optimization method 100 addresses a problem found in multiprocessorsystems, the method may also be used in single-processor systems.

Users, denoted as user 1 30A, user 2 306, . . . , user K 30K(collectively, “users 30”), represent portions of the pcode flowthroughout the multiprocessor system. Tools 80, consisting ofapplication programming interface (API) and helper functions, areavailable to both the message channel driver 50 and to the users 30.

In some embodiments, the method 100 assigns a virtual channel identifier(VOID) 60 to each user (pcode flow) 30 that uses the message channel 20.Virtual channel identifiers 60A, 606, . . . , 60K (collectively, “VCIDs60”) are available to each user 30A, 30B, . . . , 30K, respectively.Each pcode flow 30 with a VCID 60 is also capable of registering acallback address. Callback addresses 40A, 40B, . . . , 40K are featuredin FIG. 2 for users 1, 2, . . . , K, respectively (collectively,“callback addresses 40”). The callback address 40 for each user 30enables the message channel driver 50 to return to the pcode flow at theappropriate address, following processing of the message channeltransaction for that user. Each user 30 with a VCID 60 can submit onemessage-channel transaction for processing.

In some embodiments, each user 30A, 306, . . . , 30K includes arespective buffer 90A, 90B, . . . , 90K (collectively, “buffers 90”).The buffers 90 are temporary storage for message channel data that is tobe returned following a message transaction. In some embodiments, themessage channel driver 50 retrieves the returned data to the respectivebuffer 90 when processing message channel transactions.

Further, in some embodiments, the message channel driver 50 includes aqueue 110 to keep track of transactions that are waiting to beprocessed. When processing a succeeding transaction, the message channeldriver will retrieve the transaction from the queue 110. In someembodiments, the queue 110 is a first-in-first-out queue.

The users 30 of FIG. 2 are presumed to be those pcode flows in whichmessage channel transactions are to take place. Other pcode flows maynot engage in message channel transactions. Such pcode flows are thusnot assigned a VOID 60, in some embodiments. Nevertheless, as is shownbelow, in some embodiments, pcode flows for both message channeltransactions and non-message channel transaction benefit from theoptimization method 100 described herein.

In some embodiments, the message channel transaction is processed,either immediately or at some future time, by the message channel driver50. The message channel driver 50 registers an event that causes akernel within the processor-based system to run a callback function whenthe message channel transaction has completed. The user (pcode flow) 30that submitted the transaction becomes notified of the completion whenits callback function runs, enabling the user to take any furtherdesired actions subsequent to the completion.

FIG. 3 is a flow diagram illustrating a method 200 in which two tasksare sequentially processed by the message channel 20, according to someembodiments. The operations 200 of FIG. 3 are performed either in asingle processor-based system or in a multiprocessor system, such as thesystem 500 of FIG. 1. The method 200 features multiple steps beingperformed in time periods denoted to the left of each step in red. Twotasks, task 1 and task 2, are to be performed. The tasks are part of thepcode flow 30 referred to earlier, with the pcode flow issuing a messagechannel transaction in a single processor-based system or in themultiprocessor system 500. Task 1 involves a message channel transactionwhile task 2 does not.

For those tasks involving message channel transactions, the task isdivided into 1) preparation of data, 2) a transaction on the messagechannel, 3) processing of the results of the message channel, and 4)other data processing that may not be message channel related.

At a first time period, (time period 1), task 1, a first pcode flow(user) 30, begins (block 200). Following data preparation (block 202) attime period 2, the pcode flow 30 issues a message channel transaction attime period 3 (block 204), thus invoking the message channel 20. Thefirst pcode flow 30 waits for the transaction to complete (block 206),with no further processing taking place. In this example, there is atimeout period of 100 time units, and the pcode flow 30 is blockedduring that entire period, known as a blocking transaction. At timeperiod 103, the results of the message transaction are processed (block208), and task 1 is completed (block 210).

The pcode flow 30 further includes a second task, task 2. Task 2commences at time period 106 (block 212). Data processing takes place attime period 107 (block 214), and task 2 is completed by time period 108(block 216), with additional tasks to be performed following thecompletion of task 2.

FIG. 4, by contrast, features the same two tasks being sequentiallyperformed on either a single processor-based system or on amultiprocessor system such as the system 500 of FIG. 1, this time usingthe message channel optimization method 100 of FIG. 2, according to someembodiments. The first task, task 1, however, is separated into twoparts, task 1 a and task 1 b, which are processed separately.

Initially, the first part of the first task, task 1 a, is processed in amanner similar to how task 1 was processed in FIG. 3. At a first timeperiod, (time period 1), task 1, a first pcode flow 30 begins (block300). Following data preparation at time period 2 (block 302), the pcodeflow 30 issues a message channel transaction at time period 3 (block304), thus invoking the message channel 20. In this example, rather thanhaving the first pcode flow 30 wait for the transaction to complete (asin block 206 of FIG. 3), the message channel transaction is queued bythe message channel driver 50 in time period 4 (block 306). Task 1 a,the first part of task 1, is completed at time period 5 (block 308).

As with the method 200 (FIG. 3), in the method 300 (FIG. 4), the pcodeflow 30 further includes the second task, task 2. Task 2 commences attime period 6 (block 310). Data processing takes place at time period 7(block 312), and task 2 is completed by time period 8 (block 314), withadditional tasks to be performed following the completion of task 2.Note that, in FIG. 3, task2 completed at time period 108, while, in thecurrent example, task 2 completed one hundred time units sooner, at timeperiod 8.

Returning to the processing of the first task, when the message channeltransaction is issued (block 304), the transaction is being processed,just as in FIG. 3. And, just as in the FIG. 3, the transaction uses 100time periods to be processed. In FIG. 4, the transaction processing hasnot been disrupted or changed, instead, the transaction is queued by themessage channel driver 50, allowing the task 1 a processing to completesuch that the next task, task 2, may be processed.

Meanwhile, in some embodiments, when the message channel transactionthat was initiated during task 1 a completes, a hardware event isgenerated, in time period 103 (block 400). The message channel driver 50responds to the hardware event by issuing a callback to the address ofthe second part of task 1, task 1 b, in time period 104 (block 402). Thecallback address 40 for the given pcode flow (user) 30 contains theaddress. Task 1 b commences in time period 105 (block 404). Since themessage channel transaction is completed, the results processing isperformed, in time period 106 (block 406), and task 1 b ends, in timeperiod 107 (block 407).

It is instructive to compare the operations 200 of FIG. 3 with theoptimized operations 300, 400 of FIG. 4. In FIG. 3, two pcode flowtasks, task 1 and task 2, are processed in 108 time periods. In FIG. 4,the same two pcode flow tasks, task 1 and task 2, with the first taskfurther being subdivided into tasks 1 a and 1 b, are processed in 107time periods, for an improvement of one time period. Furthermore,however, there is a further opportunity for additional tasks to beprocessed sequentially following the completion of task 2, with 95 timeperiods being available between time period 8 and time period 103. And,either tasks that issue message channel transactions (such as task 1) ortasks that do not issue message channel transactions (such as task 2)may be processed during these 95 time periods. Thus, the operations 300,400 of FIG. 4 provide additional opportunities for efficient processingof message channel transactions, without the need to block one or moretransactions.

Further, in some embodiments, the processing of the task 2 transactionscommences much earlier with the method 300 than in the method 200. And,by being able to process more tasks sequentially in the 95 additionaltime periods, the cycles may provide a functional benefit to the systemprocessing the transactions. In some embodiments, the pcode issueshundreds of message channel transactions per millisecond, so thepotential benefit of using the cycles may be significant.

Recall that both the message channel driver 50 and the users 30 usetools 80 to assist with performing the optimization method 100. FIG. 5shows the tools 80 used by the optimization method 100, in someembodiments. There are four functions 72, 74, 76, and 78, which areclassified as application programming interface (API) functions and twofunctions 82 and 84, which are deemed helper functions. Functionally,the user 30 interfaces with the driver 50 (via the API functions 72, 74,76, 78), and the driver interfaces with the processor. The APIfunctions, therefore, enable the users to access the processor, via thedriver 50.

In some embodiments, the first API function 72,is_virtual_message_channel_busy, enables the user 30 to determinewhether its virtual channel is busy or idle. The VCID 60 for the user 30is provided as an input to this function 72. Recall that, based on theVCID 60, the virtual channel 70 is assigned to the user 30. If the user30 senses a request on its virtual channel 70, another request cannot besent until the first message has been processed. Thus, before proceedingwith the second message, the user 30 ascertains, using the API function72, whether its virtual message channel 70 is not busy. Further, if themessage channel request is one that returns data, the user 30 uses theAPI function 72 to determine whether the request has been completed,thus enabling the user to retrieve the returned data. The API function72 is thus essentially a handshaking mechanism between the user 30 andthe message channel driver 50. The API function 72 returns a run/busybit for the virtual message channel 70 specified by the VCID 60 for theuser 30.

In some embodiments, the second API function 74,message_channel_virtual_read, returns the contents of the virtualmessage channel 70 specified by the input, VCID 60. In some embodiments,a 64-bit message channel payload result is returned by the API function74. The message channel driver 50 returns the read information to thebuffer 90 associated with the user 30. Thus, upon invoking this readfunction 74, the user 30 will read the contents of the buffer 90.

In some embodiments, the third API function 76,message_channel_virtual_send, is the means by which the user 30 sends amessage on the message channel 20, using its virtual message channel 70.Recall that the message channel 20 is used by many disparate pcode flowsand functions between endpoints in the processor, such as to read andwrite uncore control registers, issue power management requests(PMReqs), as well as to send messages to other platform entities (e.g.,other CPUs 150, PCHs 180 in the multiprocessor system 500). Again, theVCID 60 for the user 30 is provided as an input to this function 76.Once the message is on the virtual message channel 70, the messagechannel driver 50 is able to process the message on the message channel30.

In some embodiments, the fourth API function 78,message_channel_virtual_send_PMreq, is a special version of the thirdAPI function 76, which processes a PMreq transmission. As with the otherAPI functions, the VCID 60 for the user 30 is provided as an input tothis function 78. PMreq, short for power management request, is aspecial type of transaction used by the QPI bus that interconnectsbetween CPUs (FIG. 1).

While both the users 30 and the message channel driver 50 use the aboveAPI functions, only the driver 50 uses the helper functions 82 and 84,in some embodiments. The helper functions allow facile movement of databetween the virtual channels 70 and the physical message channel 20. Thefirst helper function, message_channel_send_to_physical 82, enables themessage channel driver 50 to send data to the physical message channel20. The second helper function,message_channel_poll_physical_with_timeout 84, enables the messagechannel driver 50 to poll the physical message channel for completion ofan operation, and includes a timeout.

In some embodiments, the message channel driver 50 registers an eventthat causes a kernel within the single processor-based system or themultiprocessor system to run a callback function when the messagechannel transaction has completed. The event is a hardware event, suchas an interrupt, that indicates that the message channel 20 is no longerbusy, which means that the last thing the driver put in the messagechannel has completed.

In some embodiments, on behalf of a user (pcode flow) 30, the messagechannel driver 50 puts a message from the assigned virtual channels 70of the user into the message channel 20. The message channel driver 50understands whether the message is to return data or not. Where data isto be returned, the message channel driver 50 retrieves the data andputs it in the buffer 90 dedicated to the user 30. Subsequent to theretrieval by the driver 50, the user 30 employs API read function 74 toretrieve the contents of the buffer 90.

Once the processing of a message channel transaction on behalf of oneuser is completed, the message channel driver 50 may proceed to“connect” another virtual channel 70 to the message channel 20 on behalfof another user 30.

FIGS. 6 and 7 are flow diagrams showing operations of the messagechannel optimization method 100 in processing a send operation and aread operation, respectively, according to some embodiments. FIG. 6illustrates a send operation by one of the users 30 of either a singleprocessor-based system or a multiprocessor system, such as themultiprocessor system 500 of FIG. 1, while FIG. 7 illustrates a readoperation.

First, FIG. 6 describes the send operation. Before the user 30 can issueany transaction on the message channel 20, the user-assigned virtualmessage channel 70 must be available, in some embodiments. Thus, theuser issues the first API function 72 to determine whether the virtualmessage channel 70 is available (block 102). Once available, the user 30issues an API send function, either the general API send function 76 orthe specialized API send PMreq function 78 (block 104). The user 30 alsoregisters a callback address (block 106) that the message channel driver50 will use to return to a predetermined address of the user (block106). At this point, the message channel (send) transaction is queued bythe message channel driver 50 (block 108). This frees up the user 30 tocontinue with other transaction processing.

When the send transaction is issued by the user 30, the message channel20 may not be available. The pcode of a typical multiprocessor systemuses the message channel quite frequently, from hundreds to thousands oftimes per millisecond. Thus, until the message channel 20 is not busy,the send transaction is not processed (block 110). Once the messagechannel 20 is available, a hardware event, such as an interrupt, willnotify the message channel driver 50 that the message channel isavailable.

The message channel driver 50, however, is processing virtual messagechannel transactions for a number of different users. Once the messagechannel 20 is available and once the user is at the top of the messagechannel driver's queue 110, the message channel driver 50 sends themessage channel transaction from the user's virtual channel 70 to themessage channel 20 (block 112). Once at the message channel 20, themessage channel transaction is processed (block 114). The messagechannel driver 50 then registers an event. This event causes the kernelof the single processor-based system or multiprocessor system to run thecallback function to the callback address 40 of the user 30 (block 116).The user 30 is thus able to complete the send transaction (block 118).

FIG. 7 shows similar operations, this time where the user 30 istransmitting a read operation to the message channel 20. Again, the user30 first ensures that the virtual channel 70 is available (block 152).Once available, the user 30 issues the API read function 74 to itsvirtual message channel 70 (block 154). The user also registers itscallback address (block 156) so that the message channel driver 50 willbe able to get back to the user pcode flow 30 once the message channeltransaction is complete. The message channel driver 50 queues thetransaction (block 158).

Once the message channel 20 is available (block 160) and once the useris at the top of the message channel driver's queue 110, the messagechannel driver 50 sends the message channel transaction from the user'svirtual channel 70 to the message channel 20 (block 162). Once at themessage channel 20, the message channel transaction is processed (block164). The message channel driver 50 then registers an event. This causesthe kernel of the single processor-based system or multiprocessor systemto run the callback function to the callback address 40 of the user 30(block 166). Since the transaction is a read transaction, the messagechannel driver 50 put the contents of the read in the buffer 90 of theuser 30. The user 30 thus retrieves the contents of the buffer 90 (block168) and completes the read transaction (block 170).

The message channel optimization method and system 100 thus enablemulti-flow access to the message channel infrastructure within a CPU ofa single processor-based system or multiprocessor system. The useremploys a virtual channel to submit message channel transactions, withthe message channel driver processing the transaction “behind thescenes”. Each transaction will be processed, either immediately or atsome future time, by the message channel driver. Tasks involving messagechannel transactions as well as non-message channel transactions areprocessed more efficiently, in some embodiments.

While the application has been described with respect to a limitednumber of embodiments, those skilled in the art will appreciate numerousmodifications and variations therefrom. It is intended that the appendedclaims cover all such modifications and variations as fall within thetrue spirit and scope of the invention.

We claim:
 1. A non-transitory computer-readable medium including code,when executed, to cause a machine to perform the following operations:issue a message channel transaction to an assigned virtual messagechannel, wherein the message channel transaction is queued by a messagechannel driver; queue the message channel transaction; process asucceeding transaction following the message channel transaction withoutwaiting for the message channel transaction to be completed; receive ahardware event to indicate that a physical message channel is available;and transfer the message channel transaction from the assigned virtualmessage channel to the physical message channel in response to receivingthe hardware event.
 2. The non-transitory computer-readable medium ofclaim 1, the code, when executed, to cause the machine to furtherperform the following operations: indicate, by way of a virtual messagechannel identifier, which of the plurality of virtual message channelsis available.
 3. The non-transitory computer-readable medium of claim 1,the code, when executed, to cause the machine to further perform thefollowing operations: indicate a return address to be transferred toafter transferring the message channel transaction to the physicalmessage channel.
 4. The non-transitory computer-readable medium of claim1, the code, when executed, to cause the machine to further perform thefollowing operations: retrieve data from the physical message channel;and store the data in a buffer.
 5. A method to process message channeltransactions without performing blocking operations, the methodcomprising: issuing, by a user, a message channel transaction to amessage channel, wherein the user comprises a portion of portablemachine code (pcode) that is executed by a processor in aprocessor-based system and the message channel transaction is receivedinto a virtual message channel assigned to the user; queueing, by adriver, the message channel transaction, wherein the user is able tofurther process pcode without waiting for the message channeltransaction to complete; receiving, by the driver, a hardware eventindicating that the message channel is available; transferring, by thedriver, the message channel transaction of the user from the virtualmessage channel to the message channel, wherein the message channeltransaction is carried by the message channel to an endpoint; returning,by the driver, to the user pcode using a callback address provided bythe user; and completing, by the user, execution of the message channeltransaction.
 6. The method of claim 5, further comprising: issuing, bythe user, a function to the driver, wherein the function tells the userwhether the virtual message channel is busy or not.
 7. The method ofclaim 5, further comprising: issuing, by the driver, an event to theprocessor, wherein the event causes a kernel to run a callback functionto the callback address.
 8. The method of claim 5, further comprising:storing, by the driver, message channel transaction results stored in abuffer; and retrieving, by the user, the results from the buffer.
 9. Amethod to process two tasks in a processor-based system, the two tasksbeing executed as part of a portable machine code (pcode) executed bythe processor-based system, the method comprising: executing a datapreparation portion of a first task, the first task comprising the datapreparation, issuance of a message channel transaction, and resultsprocessing; sending a function to a processor in the processor-basedsystem, wherein the function causes the message channel transaction tobe queued by a message channel driver; and executing a second task, thesecond task comprising no message channel transaction, wherein thesecond task is executed irrespective of whether the message channeltransaction of the first task is completed; wherein the message channeldriver, upon receiving a hardware event, transfers the message channeltransaction from a virtual message channel to a message channel wherethe message channel transaction is carried by the message channel to anendpoint.
 10. The method of claim 9, further comprising: executing theresults processing portion of the first task.
 11. The method of claim 9,further comprising: sending a callback address to the message channeldriver; wherein the message channel driver calls the callback addressafter the message channel transaction is executed.
 12. An apparatus,comprising: transaction means to initiate a message channel transactionto a virtual message channel and to register a callback address; drivermeans to queue the message channel transaction by the user and, inresponse to the message channel being available, to transfer the messagefrom the virtual message channel to the message channel; channel meansto process the message; callback means to cause the driver means toregister an event to cause a kernel to run a callback function to thecallback address; and completion means to complete the message channeltransaction.
 13. The apparatus of claim 12, further comprising: a firstmeans to determine whether the virtual message channel is busy; thedriver means to indicate whether the virtual message channel is busyupon receiving the first means.
 14. The apparatus of claim 13, furthercomprising: a second means to request a read of the virtual messagechannel; the driver means to returns contents of the virtual messagechannel to a buffer upon receiving the second means.
 15. The apparatusof claim 14, further comprising: a third means to request a send of datastored in the virtual message channel to the message channel; the drivermeans to transfer the data from the virtual message channel to themessage channel upon receiving the third means.
 16. The apparatus ofclaim 12, further comprising: a fourth means to transfer data from thevirtual message channel to the physical message channel.
 17. Anapparatus comprising: processing logic to process a first task; channellogic to issue a first message channel transaction in response to theprocessing logic to process the first task; message channel driver logicto hold a reference to the first message channel transaction; whereinthe processing logic is further to start processing a second task beforecompletion of the first message channel transaction; and wherein themessage channel driver logic is further to initiate subsequentprocessing of the first task subsequent to the processing logic to startprocessing of the second task in response to an event associated withcompletion of the first message channel transaction.
 18. The apparatusof claim 17, further comprising: a queue to hold the reference to thefirst message channel transaction.
 19. The apparatus of claim 17,further comprising: a plurality of tools to be used by the messagechannel driver, the plurality of tools comprising: a busy function todetermine whether the channel logic is available or busy; a readfunction to read the contents of the channel logic; and a send functionto send data to the channel logic.
 20. The apparatus of claim 19, theplurality of tools further comprising: a send power management requestfunction to send a power management request to the channel logic.